🬤 rns.recipes

Forum / General / Thread / Export

# POST-based interface

_General · started by jrl290 on Fri, Jun 26, 2026 10:33 PM_

---

## Original post

**jrl290** · Fri, Jun 26, 2026 10:33 PM

I see someone already has a javascript library that uses WebSockets. I think that's great

For fun, I mocked up what I thought could be done using nothing but PHP and standard HTTP ports (AI assisted of course), since that's generally the limitation of shared web hosting.

The key difficulty is the one way nature of POST requests. It's always possible to access the hosted server. It's not possible to dial back to the client. So I took a particular strategy: front and back load the "pull" side of the exchange; reduce the "push"/"poll" side to a "data ready" response.

Between web servers, the "one way" issue isn't a problem. A node can just directly send a "data ready" whenever needed.

Polling of course, isn't awesome. But a lot of "live" connections on webpages do that anyway: including chat programs.

The key link to the concept though is getting data from the PHP host to the standard TCP/IP backbone nodes in order to link everything. That could be done by anyone who has more flexible hosting that could run python on custom ports. Or worst case, a polling daemon could provide a link

I just figured it might be a cheap way to expand the network. For resiliency more than for specific application use

Any thoughts on whether it's worth pursuing? I'm honestly on the fence about it's usefulness

---

## Reply 1

**Sojourner** · Sat, Jun 27, 2026 11:22 AM

Why not just use websockets as the interface? they use the same port as your other http traffic, so there's no limitation there?

Maybe I'm misunderstanding you.

---

## Reply 2

**jrl290** · Sat, Jun 27, 2026 3:14 PM

Shared hosting relies on short lived requests. Even if you were to run a php script that establishes a websocket connection, the hosting service may terminate the script if it runs too long. You also wouldn't be able to accept incoming connections while also running an nginx/apache web server since they would tie up the same port

---

## Reply 3

**Sojourner** · Sun, Jun 28, 2026 2:19 PM

> Even if you were to run a php script that establishes a websocket connection, the hosting service may terminate the script if it runs too long

Ah, that sucks.

> You also wouldn't be able to accept incoming connections while also running an nginx/apache web server since they would tie up the same port

Of course you can. You use `/` for your regular traffic and `/ws` for your websockets. Every remotely modern web server can deal with websockets.

---

## Reply 4

**jrl290** · Tue, Jun 30, 2026 6:32 PM

```

Of course you can. You use / for your regular traffic and /ws for your websockets. Every remotely modern web server can deal with websockets.

```

Yes, sorry. You are correct that apache/nginx can "upgrade" to websocket. But in that scenario it is acting like a reverse proxy to websocket on another port. If your web host doesn't allow binding to more than a few ports (80, 433...) then you can't run the websocket service and proxy to it.

Different shared hosting has different restrictions. Some allow you to open arbitrary ports locally but not accessible from outside. But again, it can be shut down for keeping an arbitrary connection/process open too long if the host has it configured that way. And then there's GoDaddy which doesn't provide ssh access, much less port binding.

But the more important thing is that short lived connections are a staple of the internet. And it also happens to coincide fairly nicely with Reticulum's ability to handle LoRa's asynchronous broadcasts. With the one small incompatibility that traffic can't always be pushed. But Reticulum is meant for arduous conditions. I think it would be a disservice to think Reticulum couldn't handle what most of the internet runs on

---